eth1+eth2 client relationship

コンセンサスはeth2。state/block作成はeth1

eth2クライアントは、PoSとシャードコンセンサスを処理し、補助的なeth1クライアントはstate、Tx、VMなどを処理する

https://scrapbox.io/files/6135e9c4206e3c001dec8a70.png

https://scrapbox.io/files/6135ea5e5b2a9c001d767c01.png

https://scrapbox.io/files/6135ea670bea220023ffbbc5.png

beacon-state

コアコンセンサスに関連するstate

バリデータセットの大きさに応じて~10-40MB

コアコンセンサスを理解し、シャードチェーンを処理するために必要な情報をすべて含んでいる。

shard chainのコンセンサスに関連する部分を処理するためには、クライアントがbeacon-stateにアクセスする必要がある

(例えば、shard chainのフォーク選択を実行するためのクロスリンク、shard chainの署名を検証するためのバリデータセット/シャッフルなど)。

eth2の設計

バリデータがeth1シャードブロックをbeacon chainにクロスリンクさせようとすると、eth2クライアントがeth1エンジンを追加で呼び出し、ブロックの実行と検証を行うことになる。

ステートフルなeth1+eth2ノードが新しいeth1シャードブロックを受信した場合、eth2クライアントはeth1エンジンに追加コールを行い、ブロックの検証とローカルステートストレージの更新を行う。

eth2プロトコルでは、すべてのブロック(ビーコン、シャード、eth1-シャード)はコアコンセンサスのPoSバリデータによって生成・署名されなければならない。このため、eth2クライアントはすべてのブロックの生成に最終的な責任を負う。

eth1シャードブロックの場合、eth2クライアントは、有効なブロックを生成するために必要なeth1ステート、トランザクション、その他の基本的なeth1構造にすぐにアクセスすることはできない。

代わりに、eth1ブロックを生成するバリデータが割り当てられると、eth2クライアントはeth1エンジンから実行可能なeth1ブロックデータ（TX、ステートルートなど）を要求する。

そして、eth2クライアントは、このeth1ブロックデータを完全なシャードブロック（add slot、proposer_index、proposer_signatureなど）にバンドルし、ブロックをネットワークにブロードキャストする

eth1エンジンが有効/有効なeth1ブロックデータを生成できるのは、今日のEthereum mainnetと同じ方法でeth1トランザクションのメモリプールを管理し、eth2クライアントからの更新によってヘッドeth1の状態に関する最新の情報を維持しているから

eth1シャード・ブロックは、eth2クライアントからeth1エンジンに提供される

このようなブロックに含まれるトランザクションは、現在のEthereumメインネットのPoWブロックと同様の方法でmempoolからクリーンアップされる

eth1シャードブロックは、mempoolのコンテンツを介して、接続先のeth2-clientからオンデマンドで生成される

このRPCメソッドとその基礎となる機能はgetWorkに似ているが、単なるハッシュではなく完全なブロックコンテンツを返す

eth1-engine

eth2-client without eth1-engine

コアとなるeth2プロトコルは、補助的なeth1エンジンがなくても実行できます。eth2クライアントは、単独でビーコンチェーンとシャードチェーン(eth1シャードチェーンを含む)を追うことができます。eth1エンジンがないと、クライアントはステートレスなeth1シャードブロックを実行することができず、完全に検証することも、有用なユーザーレベルの情報を得ることもできません。それでも、eth2コアのコンセンサスとバリデーターについての仮定に基づいて、eth1シャードチェーンの先頭を安全に見つけることができる。

eth2-client with stateless eth1-engine

バリデータを実行するためには、eth2-clientを隣接するeth1-engineとともに実行する必要がある。これは、eth1のシャードブロックが実行可能なバリデーターを持っているため、ステートレスな方法で行うことができる(eth1の状態全体をローカルに保存しない)。Beacon Commiteeは、ブロックのフォーマットと実行の妥当性をチェックするeth1エンジンへのステートレスコールを介して、シャードブロックデータの可用性とeth1に関するデータの妥当性をチェックすることができる。

バリデーター以外にも、多くのユーザー/アプリケーションノードがステートレスまたはセミステートフルなeth1-エンジンを使用して動作する可能性があります。eth2クライアントを使用して、eth1シャードチェーンの先頭を追い、ステートレスまたはセミステートレスな方法で対話する。

eth2-client with stateful eth1-engine

eth1シャードブロックを生成できるバリデータを実行するためには、eth2プロトコルを、補助的なeth1-engineとともに、完全なeth1ステートとともに実行する必要がある(ステートレスなブロック生成方法も検討されているが、ここでは簡単にするために最初の議論から外している)。ローカルの状態とtxのメモリプールを使用して、必要に応じて新しい有効なブロックを形成することができる

バリデーター以外にも、多くのユーザー/アプリケーションノードが、完全にステートフルなeth1-engineで動作する可能性がある

ENR(Ethereum Name Record)

eth1+eth2クライアントは、複数のケイパビリティを持つ1つの論理的ネットワークIDの背後にノードが存在するため、1つのENRを使用します。

eth1ケイパビリティ（状態、トランザクションなど）は、ENR内の既存のeth（または新しいeth1）キーで示される。

eth2ケイパビリティ（コアコンセンサス）は、ENR内のeth2キーで示される。

それぞれの能力の存在は、基礎となるネットワークプロトコルのクラスを話すノードの能力と意思を意味する。

th2クライアントはeth1エンジンから実行可能なeth1ブロックデータ（TX、ステートルートなど）を要求する。そして、eth2クライアントは、このeth1ブロックデータを完全なシャードブロック（add slot、proposer_index、proposer_signatureなど）にバンドルし、ブロックをネットワークにブロードキャストします。

参考文献